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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the stage 3 aspects of mobiHty management for User Equipment (UE) using IETF 
Mobile IPv4 foreign agent mode to access the Evolved Packet Core Network (EPC) through trusted non-3GPP access 
networks and for mobility management of UE between the 3GPP access network and trusted non-3GPP access 
networks. 

In particular, the present document describes the UE - Mobile IPv4 Foreign Agent (FA) interface stage 3 aspects, where 
the FA functionality is located within the access network in the non-3GPP access domain. 

The present document is appUcable to the User Equipment (UE) and the network node implementing the FA 
functionality. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] draft-ietf-mip4-rfc3344bis-06.txt (March 2007): "IP Mobihty Support for IPv4, revised". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

[3] 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses". 

[4] 3GPP TS 23.003: "Numbering, addressing and identification". 

[5] IETF RFC 5446 (February 2009): "Service Selection for Mobile IPv4". 

[6] 3GPP TS 33.402: "3GPP System Architecture Evolution; Security aspects for non-3GPP 

accesses". 

[7] IETF RFC 2794 (January 2000): "Mobile IP Network Access Identifier Extension for IPv4". 

[8] 3GPP TS 29.279: "Mobile IPv4 (MIPv4) based MobiHty protocols; (Stage 3)". 

[9] IETF RFC 3543 (August 2003): "Registration Revocation in Mobile IPv4". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPPTR 21.905 [1]. 

Foreign Agent (FA): a router on a visited network which provides mobile IPv4 routing services to the UE while 
registered as described in draft-ietf-mip4-rfc3344bis [2]. 
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Foreign agent care-of address: an address of a foreign agent with which the UE is registered as described in draft-ietf- 

mip4-rfc3344bis [2]. 

Home Agent (HA): a mobile IPv4 router on a UE"s home network which tunnels datagrams for delivery to the UE 
while it is registered on a visited network as described in draft-ietf-mip4-rfc3344bis [2]. According to 
3GPP TS 23.402 [3], the HA functionality is implemented in the PDN Gateway. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

EPC Evolved Packet Core Network 

FA Foreign Agent 

FACoA Foreign Agent Care-of Address 

HA Home Agent 

RRP Registration Reply 

RRQ Registration Request 

4 General 

4.1 IVIobility management based on FACoA 

MIPv4 is specified in draft-ietf-mip4-rfc3344bis [2] which provides two alternative modes of enabling a mobile node 
(UE) to acquire a care-of address for routing of datagrams: 

a "foreign agent care-of address" (FACoA) mode wherein a care-of address is provided by a FA through agent 
advertisement messages, or 

a "co-located care-of address" mode wherein a care-of address is acquired by the UE as a local IP address. 

For the purpose of IP mobility management while accessing the EPC through a trusted non-3GPP access network, the 
FACoA mode enables the UE to register the IP address of the FA (FACoA) located within the non-3GPP access 
network with the UE's HA for the routing of datagrams to the UE. 

4.2 Identities 

In order to support MIPv4 FA mode mobility management with the EPC, the network and mobile client shall use an 
NAI as described in 3GPP TS 23.003 [4] for user identification. The network and mobile client shall base the username 
part of the NAI on IMSI. 

The network and UE shall use the Root NAI when the UE attempts a MIPv4 registration while attached to the HPLMN. 
The Root NAI format is specified in 3GPP TS 23.003 [4]. 

The network and UE shall use the Decorated NAI when the UE attempts a MIPv4 registration while attached to a 
VPLMN. The Decorated NAI format is specified in 3GPP TS 23.003 [4]. 

4.3 Multiple PDN connectivity 

Following the establishment of a mobility binding to an initial PDN, the UE can request the establishment of a mobility 
binding with an additional PDN by including the APN of the desired PDN within a Service Selection extension defined 
in IETF RFC 5446 [5]. The Service Selection extension is included within the Registration Request (RRQ) message 
defined in draft-ietf-mip4-rfc3344bis [2]. The UE can repeat the process of sending an (RRQ) with a Service Selection 
extension to establish connectivity with additional PDNs. 
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4.4 M IPv4 security aspects 



The procedures for bootstrapping of MIPv4 foreign agent care-of address (FACoA) security parameters are described in 
3GPPTS 33.402 [6]. 

The MIPv4 security is based on the use of the authentication extensions defined in draft-ietf-mip4-rfc3344bis [2]. The 
MIPv4 signalHng messages are protected between the UE and the HA using the Mobile-Home Authentication extension 
and optionally between the UE and the FA using the Mobile-Foreign Authentication extension. 



5 FACoA procedures for mobile IPv4 

5.1 FACoA initial attach and registration 

5.1.1 General 

The MIPv4 initial attach is performed by the UE to establish a MIPv4 connection with the node acting as the HA. The 
initial attach involves the following procedures: 

Discovery of the HA address. The UE needs to discover the IPv4 address of the node acting as the HA. 

Discovery of FACoA. The UE needs to discover the IPv4 care-of address provided by the FA. 

IPv4 home address assignment. The UE needs to be assigned an IPv4 address to be used as the home address 
in Mobile IPv4 FACoA mode. The HA is responsible of assigning the home address to the UE. 

Security association establishment. The UE needs to establish a security association with the node acting as the 
HA in order to secure the MIPv4 signalling. This procedure usually consists in a shared key verification and is 
performed via MIPv4 signalling. 

5.1.2 UE procedures 

5.1.2.1 Agent discovery 

When the UE has attached to the non-3GPP access network, the UE may send a MIPv4 Agent Solicitation as specified 
in draft-ietf-mip4-rfc3344bis [2]. 

5.1 .2.2 FACoA registration 

Upon first receiving a MIPv4 Agent Advertisement message from a FA or detecting a reboot of the FA through 
inspection of the Agent Advertisement message sequence number, the UE shall select one care-of address included in 
the Mobility Agent Advertisement Extension and shall send an RRQ to the FA as specified in draft-ietf-mip4- 
rfc3344bis [2] with the care-of address included in the Care-of Address field of the RRQ message. The UE shall set the 
source address and Home Address field to the unspecified address (i.e. 0.0.0.0). The UE shall clear bits S (simultaneous 
binding) and D (decapsulation by mobile node), and set bit T (reverse tunnelling) to request reverse tunnelling. The UE 
shall also include the NAI extension as specified in IETF RFC 2794 [7]. 

As part of MIPv4 security, the UE shall include the Mobile-Home Authentication extension within the RRQ as 
specified in draft-ietf-mip4-rfc3344bis [2]. The UE shall set the authenticator and SPI fields of the of the Mobile-Home 
authentication extension to the MN-HA key and associated MN-HA-SPI generated as described in 3GPP TS 33.402 [6]. 
If the non-3GPP access specific procedures require a security association between the UE and FA, the UE shall also 
include the Mobile-Foreign Authentication extension within the RRQ as specified in draft-ietf-mip4-rfc3344bis [2]. The 
UE shall set the authenticator and SPI fields of the of the Mobile-Foreign authentication extension to the MN-FA key 
and associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6]. 

If the UE already knows the IP address of the HA (e.g. when the HA address is pre-configured) the UE shall include 
that IP address in the Home Agent field. 
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If the UE does not know the IP address of the HA, the UE shall include the unspecified address (i.e. 0.0.0.0) in the 
Home Agent field. 

If the UE has established a mobility binding with a given PDN and connection to an additional PDN is desired, the UE 
shall include the APN of the desired PDN within a Service Selection extension as defined in IETF RFC 5446 [5] within 
an RRQ as described in draft-ietf-mip4-rfc3344bis [2]. 

If the UE is registered on a trusted non-3GPP access network and maintenance of its registered mobility binding is 
desired, the UE shall re-register before the expiration of the lifetime of the registration as specified in draft-ietf-mip4- 
rfc3344bis [2]. If the UE has established connectivity to multiple PDNs, the UE shall re-register all mobility bindings. 

When the UE receives a Registration Reply (RRP) from the FA, the UE shall perform the validity checks and process 
the message as specified in draft-ietf-mip4-rfc3344bis [2] to include validation of the Mobile-Home Authentication 
extension and, if present, the Mobile-Foreign Authentication extension. After receiving a successful RRP, the UE shall 
store the HA address and the home address and may send data using the home address. 

5.1.3 FA procedures 

5.1 .3.1 Agent advertisement 

When the FA receives a MIPv4 Agent Solicitation, the FA shall send a MIPv4 Agent Advertisement to the UE as 
specified in draft-ietf-mip4-rfc3344bis [2]. The MIPv4 Agent Advertisement shall include only the Mobility Agent 
Advertisement Extension. 

The FA shall send an unsolicited MIPv4Agent Advertisement when it receives a trigger that a new UE has attached to 
its link and it has not received a MIPv4 Agent Solicitation from the UE. In this case the FA shall set the destination 
address of the MIPv4Agent Advertisement shall be the "limited broadcast" address (i.e. 255.255.255.255). 

For both solicited and unsolicited MIPv4Agent Advertisements, the FA shall set the following bits in the Mobility 
Agent Advertisement Extension: R (registration required), F (foreign agent) and T (reverse tunnelling) (see draft-ietf- 
mip4-rfc3344bis [2]). The FA shall include at least one care-of address in the Mobility Agent Advertisement Extension. 

5.1.3.2 UE registration 

When the FA receives an RRQ from the UE, the FA shall process it as specified in draft-ietf-mip4-rfc3344bis [2] and 
3GPP TS 29.279 [8]. The FA shall validate the Mobile-Foreign Authentication extension if present. 

If the RRQ is accepted by the network, the FA shall send an RRP to the UE as specified in draft-ietf-mip4- 
rfc3344bis [2]. If the non-3GPP access specific procedures require a security association between the UE and FA, the 
FA shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in draft-ietf-mip4- 
rfc3344bis [2]. The FA shall set the authenticator and SPI fields of the Mobile-Foreign Authentication extension to the 
MN-FA key and associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6]. 

5.2 FACoA handover 
5.2.1 General 

A MIPv4 handover occurs when the UE changes access between trusted non-3GPP accesses. A change in the local 
point of attachment will trigger a MIPv4 handover procedure. In this case, the UE has already an established binding at 
the HA, and the handover procedure will update the care-of address (FA IP address) of its binding. 



5.2.2 UE procedures 



The UE may detect a movement, based on the ICMP Lifetime field of the router advertisements: if the lifetime of an 
agent advertisement has expired, and the UE has not received another Agent Advertisement message from the same FA, 
then the UE can consider itself having moved. 

Another method for the UE to discover that it has moved is based on the advertised prefix: a change in the advertised 
prefix can aid the UE in determining that it has moved and to register with the newly advertised prefix. This method is 
only used when all mobility agents use the prefix length extension in their agent advertisements. 
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NOTE: The UE can also detect the movement based on an indication from the layer 1 and layer 2. 

Upon detecting movement, the UE shall register with the new FA as specified in draft-ietf-mip4-rfc3344bis [2] by 
sending an RRQ with the care-of address of the new FA included in the Care-of Address field of the message. The UE 
shall set the source address to the unspecified address (i.e. 0.0.0.0). The UE shall clear bits S (simultaneous binding) 
and D (decapsulation by mobile node), and set bit T (reverse tunnelling) to request reverse tunnelling. The UE shall also 
include the N AI extension as specified in IETF RFC 2794 [7] . 

As part of MIPv4 security, the UE shall include the Mobile-Home Authentication extension within the RRQ as 
specified in draft-ietf-mip4-rfc3344bis [2]. The UE shall set the authenticator and SPI fields of the of the Mobile-Home 
authentication extension to the MN-HA key and associated MN-HA-SPI generated as described in 3GPP TS 33.402 [6]. 
If the non-3GPP access specific procedures require a security association between the UE and FA, the UE shall also 
include the Mobile-Foreign Authentication extension within the RRQ as specified in draft-ietf-mip4-rfc3344bis [2]. The 
UE shall set the authenticator and SPI fields of the of the Mobile-Foreign authentication extension to the MN-FA key 
and associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6]. 

If the UE had maintained connectivity to multiple PDNs prior to the handover, the UE shall then update its mobility 
binding with each additional PDN using the procedure described in subclause 5.1.2.2. 

The UE shall include its known home address and the IP address of the HA within the RRQ. 

5.2.3 FA procedures 

The FA shall respond to agent solicitations sent by the UE, by addressing these agent solicitations to the unicast layer 2 
and layer 3 addresses. 

When the FA receives a RRQ from the UE, the FA shall process it as specified in draft-ietf-mip4-rfc3344bis [2] and 
3GPP TS 29.279 [8]. The FA shall validate the Mobile-Foreign Authentication extension if present. 

The FA relays the RRQ to the HA IP address found in the registration message. 

If the network accepts the RRQ, the FA shall send an RRP to the UE as specified in draft-ietf-mip4-rfc3344bis [2]. If 
the non-3GPP access specific procedures require a security association between the UE and FA, the FA shall also 
include the Mobile-Foreign Authentication extension within the RRQ as specified in draft-ietf-mip4-rfc3344bis [2]. The 
FA shall set the authenticator and SPI fields of the Mobile-Foreign Authentication extension to the MN-FA key and 
associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6]. 

5.3 FACoA deregistration 

5.3.1 General 

MIPv4 deregistration is either due to a detach or a return home event. 

When the UE returns home, it will need to deregister from the HA. This can occur when the UE returns to the 3GPP 
network. In this scenario, the UE will de-register from the PDN-GW acting as an HA. 

5.3.2 UE procedures 

5.3.2.1 Network-initiated deregistration 

Network-initiated deregistration can occur due to an administrative reason or detecting the UE's leaving the trusted non- 
3GPP access network. Network-initiated deregistration takes the form of registration revocation as defined in 
IETF RFC 3543 [9]. The FA or the HA can initiate registration revocation. 

The UE can be informed that its mobility binding no longer exists through inspection of the Agent Advertisement 
sequence number as described in draft-ietf-mip4-rfc3344bis [2]. 

Upon determining that its mobility binding no longer exists with the FA and HA, the UE shall locally clear its mobility 
binding. 
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5.3.2.2 UE-initiated deregistration 

The UE deregisters from its HA when it determines that it is back home or as part of a UE-initiated detach from the 
serving trusted non-3GPP access network. The UE can determine that it is back home through inspection of the H bit 
and advertised prefix within a received agent advertisement. 

In the case of UE deregistration upon returning home, the UE sends an RRQ with the destination address set to the HA's 
address, with a Lifetime field set to to indicate deregistration, and with the care-of address set to the UE's home IP 
address. The RRQ will be formatted and handled as specified in draft-ietf-mip4-rfc3344bis [2]. The UE shall include 
the Mobile-Home Authentication extension within the RRQ as specified in draft-ietf-mip4-rfc3344bis [2] and shall set 
the authenticator and SPI fields of the of the authentication extension to the MN-HA key and associated MN-HA-SPI 
generated as described in 3GPP TS 33.402 [6]. 

In the case of UE deregistration as part of a UE-initiated detach from the serving trusted non-3GPP access network, the 
UE sends an RRQ with the Destination Address field set to the FA's address, with a Lifetime field set to to indicate 
deregistration, and with the Care-of Address field set to the FA care-of address previously registered with the HA. The 
RRQ will be formatted and handled as specified in draft-ietf-mip4-rfc3344bis [2]. The UE shall include the Mobile- 
Home Authentication extension within the RRQ as specified in draft-ietf-mip4-rfc3344bis [2] and shall set the 
authenticator and SPI fields of the of the authentication extension to the MN-HA key and associated MN-HA-SPI 
generated as described in 3GPP TS 33.402 [6]. If the non-3GPP access specific procedures require a security 
association between the UE and FA, the UE shall also include the Mobile-Foreign Authentication extension within the 
RRQ as specified in draft-ietf-mip4-rfc3344bis [2] and shall set the authenticator and SPI fields of the Mobile-Foreign 
Authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6]. 

If the UE has established connectivity to multiple PDNs, the UE shall perform this deregistration process for each PDN. 
The UE shall include a Service Selection extension as defined in IETF RFC 5446 [5] denoting the APN of the PDN to 
be deregistered in the RRQ. 

Once the deregistration request is accepted, the UE receives an RRP directly from the HA in the case of a "back home" 
deregistration or from the HA through the FA in the case of a deregistration as part of a UE initiated detach in the 
serving non-3GPP access network. The UE shall perform the validity checks on the Mobile-Home Authentication 
extension, and, if present, the Mobile-Foreign Authentication extension and processes the message as specified in draft- 

ietf-mip4-rfc3344bis [2]. 

5.3.3 FA procedures 

5.3.3.1 Network-initiated deregistration 

Network-initiated deregistration can occur due to an administrative reason or detecting the UE's leaving the trusted non- 
3GPP access network. Network-initiated deregistration takes the form of registration revocation as defined in 
IETF RFC 3543 [9]. The FA or the HA can initiate registration revocation. 

The FA can initiate deregistration by sending a Registration Revocation message, as defined in IETF RFC 3543 [9], to 
the address of the HA. The Source Address field will be the care-of address of the FA registered by the UE, and the 
Home Address field will be the home IP address of the UE whose registration is being revoked. The HA will respond 
with a Registration Revocation Acknowledge message as specified in IETF RFC 3543 [9]. 

The HA can initiate deregistration by sending a Registration Revocation message to the FA providing the care-of 
address for the UE. The FA shall process the Registration Revocation message as described in IETF RFC 3543 [9] and 
respond to the HA with a Registration Revocation Acknowledge message. 

Following successful registration revocation, the FA may provide an indication to the UE that its mobility binding has 
been reset by appropriate setting of the Agent Advertisement sequence number as described in draft-ietf-mip4- 
rfc3344bis [2]. The FA may also initiate other actions to terminate the mobility session through other means that are 
beyond the scope of this document. 

5.3.3.2 UE-initiated deregistration 

When the FA receives an RRQ with a Lifetime field set to from the UE, the FA shall process it as specified in draft- 
ietf-mip4-rfc3344bis [2] and 3GPP TS 29.279 [8]. The FA shall validate the Mobile-Foreign Authentication extension if 
present. 
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The FA shall relay the RRQ to the HA IP address found in the RRQ. 

If the HA accepts the RRQ, the FA shall send an RRP to the UE as specified in draft-ietf-mip4-rfc3344bis [2]. If the 
non-3GPP access specific procedures require a security association between the UE and FA, the FA shall also include 
the Mobile-Foreign Authentication extension within the RRQ as specified in draft-ietf-mip4-rfc3344bis [2]. The FA 
shall set the authenticator and SPI fields of the Mobile-Foreign Authentication extension to the MN-FA key and 
associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6]. 

In case of a return home event, the deregistration procedure occurs between the UE and the HA; as such, the FA is not 
involved. 
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